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METTHOD AND APPARATUS FOR RELAYING SESSION INFORMATION 

FROM A PORTAL SERVER 

ABSTRACT 

5 

For a portal server system for managiiig a ooUection of associated portlets responsive to 
user requests to access a web application, the invention provides apparatus and methodology 
including: a portlet appUcation session object for saving parameters ftom user requests of 
associated portlets; and. a portlet application communication client linked to said porliet 
10 appUcation session means for communicating between said associated porflets and said weto 
appUcation to convey user requests received from said associated portlets to said web 
appUcation. 
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METHOD AND APPARATUS FOR RELAYING SESSION INFORMATION 

FROM A PORTAL SERVER 

padtground of the In ventioii 

Field of the Inventioit 

This invention relates to the hitemet, more particiilarly to methods and apparatus for 
producing and using portals and portlets in web applications to provide enhanced capabilities for 
vfdb sites. 



n«,iieinl Baekgroimd 

The World Wide Web brou^t a paradigm drift to communications over the Latem^ 
cbnveying graphical information to users. With the advaii of the Web there was and stfll is 
demand for in<areasing.communicability and broad connectivity. 
15 The Portal (previously known as a web portal) has brougjit a major paradigm shift in 

internet space. A web site that offers an array of resources or services sudi as email, forums, 
search engines, databases or other iriforaiation may be considered to be a portal. The first web 
portals may have been online services. For the first time, users surfing the internet were able to 
see web pages that were assembled with and offered information coming firam various sites in the 
20 worid wide web, yet the aggregation's constitution was transparent to tiie user. A user making 
use of a typical web browser sees a cohesive web page displayed. The origination of different 
parts of the page fi-om various internet sites not associated with the web site being viewed is not 
readily apparent These parts are termed Portlets. 

Portlets are tiie visible active components ead users see wiihin their portal pages. Similar 
25 to a window in a PC desktop, each porttet "owns" a portion of the browser or Personal Digital 
Appliance srareen where it displays results 

From a usm's view, a portlet is a content channel or application to which a user 
subscribes, adds to th«r personal portal page, and configures to show personalized coxHeat 
From content providers* view, a portlet is a means to make available their content 



CA9-2002-0069 




CA 02406713 2002-10-04 



Fiom a portal administrators view, a poitlet is a contmt contains that can be registered 
with the portal, so that users may subscribe to it 

From a portal's point of view, a portlet is a component mdered into one of its pa^ 

From a technical point of view, a portlet is a piece of code or a small application that runs 
S on a portal server and provides contmt that is to be embedded into portal pages. In the simplest 
terms, a portlet may be a Java™ servlet that opwates inside a portal. 

Each part (portlet) of a given page (typically sourced from different places in the world 
wide web) can collaborate with another part(portlet) of the same page to achieve hi^er function 
for a user surfing or accessing the page. Thus, a portal becomes the single point of access for 
10 multiple users, via multiple channels, to multiple soiirces of information. 

Portals can be applied in various business models, namely: business to consume, 
busmess to business, or business to enterprise. The key to quick adoption of the portal paradigni 
ties strongly to its ability to integrate existing web application data into the portal framework in a 
seamless fiishion, 

IS However, various technical hurdles still exist for such seamless web application 

integration into portal. 

Prior art Limitations in Integrating Web Applications Into Portals 

When users access a portal page, the original http request for each user is directed 
20 towards the portal server. Each of flie poitlets has its own independent session called portiiet 
session. When a portlet needs to render information that com^ from a given web ^plication, 
diere is no mechanism to maintain these multiple http requests; generated from various portlets 
to a given web application; as one cohesive http session from the point of view of the web 
application. On top of that, there is no existing mechanism to relay session information between 
25 the multiple portlet sessions to the web application session. Session information fiom the portlets 
is required to be forwarded to fte web application in order for the web application to rend&c 
correctly. Examples of important session information required for forwarding from portlet 
sessions to tixe wd> application include locale information, user agent and session time out 
information. 
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There are limitations in the prior art concerning how the following portal artifects work 
togeth^ with existing web q;)pIicattons. The implemoitation of integration of web plications 
into portal architecture is not w^ defined. These oitities include: 

Original http request to a portal 
S A portlet session within a portal 

A ht^ request from the portal to the pertinoit web application 

When differoit users access a portal page, the ori^nal http request for each user is 
directed towards the portal server (a). The ori^nal ht^ session for eadi user is also oitirely 
10 "owned" hy the portal server. Eadi of the portlets has its own mdq)endeiit session called a portly 
session Whoi a pntlet needs to render information that comes from a given web ^licatimi, (b), 
there are typically the^llowiiig technical hmdles: 

i. • TTiere is no existing mediaDdsm for a portlet to generate http requ^ and 
responses to and from the backend web application. 
15 ■ j. xhere is no «dsting mechanisA to manage multiple requests and responses to a 
calling portlet (and the portlet session) mapping correctly with multiple requests 
and responses to a backoid web application (and the web plication's session). 
Eadi (both pordet and web plication) maintains its user session accordingly. 

20 This gets complicated when multiple porttets call the same wefeappUcation, with the web 

application treating these multiple portlets requests within the same web plication session, 

k. There is No existing mechanism to relay session information between the multiple 
portlet sessions and the web application's session. 

25 When a well defined set of portly widiin Ifae same portlet pUcation interact with the 

one web appUcation at the backend, aU the participating portlets must be able to retrieve and 
forward flie ooitect session information to the web pUcation at the backend such fliat the 
information rendered fiom the web pUcation is consistent wifli the setting of ftat of the portal 
of the portlets. Examples of such setting includes locale information, user agent of that particular 
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access etc. For example, the responses sent from the web ^plication must be using the same 
locale with the portlet in the portal server who displays it. 

There is no existing mechanism for single sign on such that the portal user's credentials 
will not be challenged by the backend web application. This is a critical lequiiement The 
S absence of it will result in the usar's credentials being challenged when the user moves from one 
part of a wd> page to a dififerent part of the same web page; as the porti^ have dififeient 
ori^nations and identification requir^ents. 

There is no existing mechanism for syndbronization of multiple requests or responses 
between portiets of a given portlet application and the pertinmt web application backend. 
10 The prior art has limitations concerning how multiple portiets within the same portlet 

application can collaborate with one another (sharing the same context) as well as with the 
various integrated web {^plications dynamically is not defined. 

One Usage Scenario involving multiple portiets collaborating by sharing the same 
'context' dynamically will serve to concq)tually illustrate the limitation: 
IS With three portiets being displayed on die same portal web page: 

- one portiet shows the account summary by displaying a list of accoimts 

- the second portlet shows a ffven accoimt's list of outstanding invoices 

- the third portiet shows a given account's order history summary 

20 The second and the tiiird portiets are contextually bound to the first portlet c!^iuanically, 

reflecting outstanding invoices (2"^ portiet) and order history (3*^ portiet) and are synchronized 
with an account selected fix>m the account list of die first portiet 

Limitations of tiie prior art: 
25 i. No mechanism exists to define a sub-grouping of portiets within a portiet application tiiat 
would work collaboratively. 

j. No mechanism exists to define a context (that can be dynamically changed) shared among 
this sub-group of portiets within a given portiet application: example of context here is 
30 the selected account in portiet 1 , such account selection can be changed dynanoically* 
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k. No mechanism «dsts to detect the change in context dynamically: exan^e of fhe change 
of selection from one account to anottier account from the account list in poitlet I of the 
above example. 

1. No medianism exists to register a ptedefmed action (or responses) for eadipartidp 
portlets within the sub-^o\q> of poitl^ that share the same context example of 
displaying the list of outstanding invoices (action in portlet 2) when flie context is 
changed (from one account selection to another in portlet 1). 

m. No mechanism exists to relay that dynanaic context to the relevant integrated web 
i^lications ■ . 

There is no mechanism existing m the prior art to d^Bne a r^resh sequence for a group of 
pordets widiin a portlet application 

i. Hiate is no i»ovision today for a portal designer to spedfy fbe refresh order of a givai set 
of portlets bong displayed. 

In our scenario above, the portal designer would want to have the first portlet (account 
Ust) refreshed first, the second portlet refreshed second etc so that the 2"* and the 3"* 
portlets automatically have. Defined actions (when the portlet is deployeiQ taking place in 
a correct sequence. 

There is a lack of a well defined medjanism in portal ardiitecture to support the 
aggregation of portlets based on busuiess rule and user profiling information inchiding the users' 
role. 

i. There is no existmg mechanism to define aggregation of portal resources per user based 
on business rules. 
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Example: all teenage portal users see one group of portlets. all senior portal users see 
another group of portlets. 

5 j. Thereisnoexistingmechanismforsuchrulebasedanduserbasedaggregationofportlets 
that is perfonned dynamically at runtime. 

There is no sharing of portal level busmess ndes and user profile information with 
pertinent integrated back end web applications. 
10 niere is no sharing of business rules or user s^entation infomiation with an integrated 

web appUcation such that these rules and user segmentation can be consistent across a portal and 
its integrated backend web appUcation. For example, if there is a rule defining the age range of a 
teenager, such a rule should be visible and applicable to the tategrated web appUcation for 
comnstaicy. 

Portlets 

Portlets are the visible active components that the end users see within their portal web 
pages. Similar to a wmdow hi a PC desktop. ead» portlet "owns" a portion of the browser or 
20. PDA (Personal Digital AppUance) screen where it displiqrs portlet spedfic mformation. 

Pftrtlat a pplication 

Portlets can also be grouped together hi a portlet appUcation. Portlet applications are 
distributed and deployed usmg Web arduve files (WAR). There are portlet specific extensions to 
25 tiie standard Web appUcation deployment desCTiptor. 

Pnrtlet Messages 

Portlet messages are used for flie communication between two portlets usmg portlet 
actions and portlet messages. The sendmg portlet creates a portlet action, encodes tiie action mto 
30 a URL. When the URL is addressed. e.g. by a user trying to acoompUsh an task, Ihe action 
Ustener is called and sends aportlet message to send the necessary data. 
CA9-2002-0069 ^ 



m- 



10 



CR. 02406713 2002-10-04 



Porflet Session 

A Porflet session is created for each porflet instance for each user logging on to maintain 
sessi<m information for each user par poifl^ instance. 

^ynfimarv of the Invention 

The various embodiments of the invention herdn address shortcomings of die prior art 
The invention provides a mettiod of relaying session information from a portal to 
associated porttets to tiie bade end appHcations. This enables die relaying of session 
information from portal to die back end web appUcation. making it possible for flie web 
apptication to bdiave consistenfly according to ftie session information provided by portaL 

An embodiment of tiie invention provides a user session informaiion store (moping 
table) for storing user sessTon information. The associated porttets have porflet request parameter 
mai>s storing data and instructions from user requests to flie porttets. thesie parameters from flie 
porflet requests are being relayed to fl»e http requests from tiie said porflet to tiae web appUcation 
15 badcend. 

Critical session inforaiation like locale; session time out information can now be relayed 
to the backend web application. 

Witii an embodiment of this invention, it is now possible to have a session rday 
implementation to for flie sharing of common session data between a portal server and its 
20 ba«*end web appUcation, enabling flie back end web appUcation to receive information from flie 
portal server to be exploited by flie back end web appUcation, wifli back end web appUcation 
responses synchronized with that of the portal servor. 

One enibodiment of flie invention provides apparatus for displaying to a user a web portal 
for a web qjpUcation, flie w«* portal displaying a plurality of associated porflets, sharing 
25 information wifli each otiier, accessible by tiie user, mduding: 

a portal server for operating a web portal to provide access to flie web ^plication; 
a porflet appUcation for operating on ttie portal server, for managmg a coUection of 
associated porfl^; the porfl^ appUcation includes: 

means to initiate porflets on requests of a user to access flie w«a> application; 
30 means to manage a porflet appUcation session object for flie porilets; and, 
CA9-2002-0069 
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a portlet plication session object data store controlled by the pordet application session 
object for saving paramet^ ftom usa requests for assodatiDg the pordets widi the wifli die 
poxdet application session object 

The i^yparatus of the invoition may include a pordet iqn>Ucatio>^ communication dieot in 
5 die pordet iqipUcation for comraunicating between die pordet application session object and die 
wd) i^lication to conv^ user requests recdved firom the assodated pordets to die wd> 
application. The pordet application may assign a common key to eadi pordet associated widi a 
pordet application session abject. 

Anotiier embodiment of die invention provides an apparatus for displaying a web portal 
10 for a web application to a plurality of users, die web portal displaying a plurality of porttets, 

sharing information, accessible by the users; including: 

a portal server for operating a web portal to provide access to die web application; 

a pordet application for operating on die portal sjerver for each of die plurality of users, 
• for managing a collection of assodated pordets for eadi of die plurality of users; 
1 5 eadi the pordet application indudes: 

means to initiate pordets on requests of one of die pluraUty of users to access die web 

application; 

means to manage a pordet plication session object for die pordets; and, 
a pordet appUcation session objed data store oontitoUed by die pordet appUcation session 
20 object for saving parameters fiom user requests for associating die pordets widi die widi die 

pordet qiplication session object 

Anodier embodiment of die invention provides apparatus for displaying to a user a web 
portal for a phirality of web applications, die web portal displaying a pluraUty of assodated 
portlets, sharing information widi eadi odier, accessible by die user, including: a portal server 
25 for operating a web portal to provide access to die web application; a ptarality of pordet 
applications relating respectively to die pluraKty of web applications for operating on die portal 
server, each pordet application being adapted to managing a collection of assodated pordets; 
each the portlet application includes: 

means to initiate portlets on requests of a user to access one of die pluraUty of web 

30 application; 
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means to manage a pordet application session object for the portlets; and» 
a porfl^ application session object data store controlled by the portiet application session 
object for saving parameters fiom user requests for associating the portlets of the portiet 
application witii the vnUi the pordet application session object of the pord^ application session. 
S Another aspect of die apparatus of the invention includes a user session infomoation table 

adapted to connect to multiple web applications with die pord^ application sesdon object 

Still another embodunCTt of die invention provides iq;>paratus for displaying to a uso: a 
web portfid for a web application, the web portal displaying a plurality of associated pordets, 
sharing information with each othcnr, accessible by the user, including: 
10 a portal server for operating a web portal to provide access to the web application; 

a pordet application for operating on the portal server, for managing a collection of 
associated portlets; 

the porflet application including: 

means to initiate a first portiet on request of a user to access the web application; 
1 S means to create a pordet application session object for the user for die first portiet; 

means to save parameters from the request; 

means to generate additional pordets associated widi the £u:st pordet on further requests 
of the user to access die web application; 

a pordet application session object data stoie controlled by die pordet application session 
20 object for using the saved parameters for associating die additional pordets with the with the 
pordet application session object; and, 

means to create a pordet application communication cliait (htfpClient) for 
communicating with the pordet application session object and die web application to convey user 
requests received from die first and additional pordets to the web implication. 
25 The apparatus may include a pordet application communication cliOTt in die pordet 

application for communicating between die pordet application swsion object and die web 
application to convey user requests received from die associated pordets to the web application. 

The portiet application preferably assigns a common key to each portiet associated with a 
pordet application session object. 
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A user session infonnation table adapted to cotmect to multiple web applications with the 
portlet application session object may advantageously be provided. 

Another embodimrat of the invention provides apparatus for displaying to a user a w^ 
portal for a web application, the web portal displaying a plurality of associated portlets, sharing 
5 information with each other, accessible by the user; including: 

a portal server operstmg a web portal to provide accos to the web i^lication; 
a portlet explication operating on Hie portal server, for managing a collection of 
associated portlets; 

fbe portlet application including: 
1 0 means to initiate portlets on requests of a user to access the wd> lwlicatioI^ 

means to manage a portlet application session object for the portlets; and, . 
a portlet application session object data store controlled by the portlet application session 
object for saving parameters fiom user requests for associating the portlets with the with the 
portlet application session object 
15 Another aspect of the invention provides a method of sharing information between a 

plurality of associated portlets in a web portal including: granting access for each of the plurality 
of associated portlets to a portlet data store; permitting each of tiiie plurality of associated portlets 
to write data to the portlet data store and to read stored data from the portlet data store. 

The me&od above may advantageously provide a system wherein the associated portlets 
20 are managed by a portlet application adapted to operate on a data processing system; wherein the 
portlet data store ccnnprises portlet application storage managed by a portlet s^plication session 
object which controls reading and writii^ of data by the associated portlets in the data store 
permitting exchange of data among the associated portlets of the portlet application. 

Anoth^ aspect of Ae invention provides q)pamtus for sharing information between 
25 multiple associated portiets in a web portal including: a pordet application for manag^ig the 
multiple associated portlets; a portiet application data store; means for granting read/write access 
to the data store by the multiple associate portiets to liable the portiets to exchange data among 
each other. 



CA9-2002-0069 



10 



CA 024067X3 2002-10-04 



Yet anolher aspect of the invention provides a porUet (appUcation) server capable of 
operating on a portal server for hosting multiple associated portlets in a web portal including: 
means for managmg llie multiple assodated portlets; 
means for managing a poid^ application session object; 
5 a portlet application data stoie managed by ttie portlet application session object for 

granting readMrite access to the data store to the multiple associate portlets to enable the 
assodated portlets to exdiange data among each other. 

Ano&er aspect of the invention provides a portlet (appUcation) server capable of 
operating on a portal server fiw hosting multiple assodated portlets in a web portal induding: 
10 means for managing die multiple assodated portlets; 

means for creating and managing a portlet appUcation session ol^ect; 
a portlet appUcation data store created and managed by die portlet appUcation session 
object for granting read/write access to die data store to die multiple associate ptaflets to enable 
the assodated portlets to exdiange data among each odier. 
15 Advantageously, die portlet appUcation assigns a common key to each portlet assodated 

widi a pordet ^pUcation session object. 

Anodier aspect of die invention provides a portlet application capable of operating on a 
portal server for hosting multiple associated portlets in a web portal accessible by a user, 
induding: 

20 pordetappUcati<mmeansformanagingthemultipleassodatedportlets; 

portlet i5»pUcation means for managing a portlet appUcation session object for die user, 
portlet appUcation means for granting die key to eadi assodated portlet for oonttoUing 
access to die portlet aiq;>lication object. 

StiU anodier aspect of die invention provides a portlet appUcation capable of operating on 
25 a portal server for hosting multiple assodated portlets in a wA portal accessible by a user, 
including: 

portlet appUcation means for managing die multiple assodated portlets; 

portlet appUcation means for creating and managing a portlet appUcation session object 

for the user. 
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portlet application means for creating and managing a key for the user for the portlet 
application session object; 

portlet application means for granting the key to each associated portlet for controlling 
access to the portlet application object 
5 Advantageously one portlet plication is assigned to each user and one key is assigned 

respectively for each user to respective pordet application objects for each portlet application. 

Anothtt- aspect of the invention provides apparatus for displaying to a user a web portal 
for a web application including: 

a portal server for operating a web portal to provide access to the web application by a 

10 user, 

a portlet application^ for managing a collection of associated portlets» for operating on the 
portal server; 

a portlet application session object for the user for the associated portlets; 

a portlet application session object data store coh§oUed by the portlet application session 

15 object; 

a porflet appUcation communication cKent linked to flie portlet application data store for 
communicating between the associated porflets and the web appUcation to conyey user requests 
recdved fiom the assodated pordets to the web application; 

die communication cUent having a request buffer for storing and synchronizing requests 
20 fiom the assodflt^ porflets to enable the communication client to generate syndironized to die 
web application. 

Preferably die portlet application communication client is adapted to send information 
includmg requests over a network to a web application and receive information including 
responses to the requests from the web application. 
25 Another aspect of flie invention provides apparatus for displaying to a user a web portal 

for a web application including: 

a portal server for operating a web portal to provide access to the web appUcation by a 

\iser; 

a portlet application, for managing a collection of associated porflets, for operating on flie 
30 portal server, 
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a portlet application session object for the user for the associated portlets; 

a portlet application session object data store controUed by the portlet application session 

object 

a portlet application communication client linked to the portlet appUcation data store for 
5 communicating between the associated portlets and Ae web appUcation to convey user requests 
lec^ved from the assodated portlets to die web application; 

the communication cUent having a request buffer for storing and serializing requests fiom 
the assodated porflets to enable fte communication dient to generate serialized to Ae web 
implication. 

10 Preferably, theportlet application communication dient is adapted to send information 

induding requests over a network to a wd) appUcation or wd) appUcation server and tecdve 
information induding resijonses to tiie requests from tiie web qyplication. 

Anotiier aspect of the invention for a portal server adapted to operate a web pwtal to 
provide access to a web appUcation; having a portlet appUcation operating on the portal servw, 

15 for managing a collection of associated portlets; wherein the portlet application indudes: means 
to initiate portlets on requests of a user to access the web application; means to manage a portlet 
appUcation session d»ject for the portlets; and, a portlet appUcation session objed data store 
contioUed by the portlet appUcation session object for saving parameters from user requests for 
assodating ttie porflets with the with the portlet appUcation session object, the apparatus 

20 induding: 

a pwtlet iq)pUcation communication client (ht^ent) Unked to the portlet application 
data store for communicating between the assodated porflets and &e web ^pUcation to convey 
user requests recdved from the assodated portlets to the web appUcation; 

&e portlet appUcation communication cUent having a user session information store 
25 (mapping table) for storing user session information induding selected information from the set 
of the foUowing user session inforaiation: user id. user credentials, language preferences, session 
timeout information, session id, etc. for mapping the user session information to a corresponding 

session of the web application. 

The session timeout information preferably indudes session timeout information of the 

30 portal server and the wd> application. 
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Another aspect of the invention provides portlet application, for managing a coUection of 
assodated porUets in a portal, for operating on a server providing access to a web application by a 



user; 



the associated porflets having portlet request parameter m^s storing data and instructions 
5 fiomusor requests to the portlets; 

a porflet appUcation session object for the user for the associated portlets; 
a portlet ^pUcation session data store controlled by flie portlet appUcation session object; 
a portlet appUcation communication cUent (httpClient) linked to the portlet appUcation 
data stoi© for comniunicating between the associated portlets and flie web q?pUcation to convey 

10 user requests received fiom the associated portlets to the web application; 

the conrniunication cUent having a request buffe for stormg requests fiom portlet r^ 

parameter maps of the associated pordets to cmble the communication client to provide data and 
instructions for the web application. 

Another aspect of the invention provides a pordet application communication cUent 
15 (httpCaient) linked to the portlet application data store for communicating between the associated 
portlets and the web application to convey user requests received ftom the associated portlets to 
die web i^pUcation; 

the portlet plication communication client having a user session information store 
(mapping table) for storing user session hrformation including selected information fix)m the set 
20 of the following user session mformation: user id, user credentials, language preferences, session 
timeout information, session id. etc. for mapping the user session information to a corresponding 
session of the wd> ««»pUcatioin the session timeout infonnation including session timeout 
informati<m of the portal searvar and flie we appUcation. 

Preferably the above indtades synchronization means for the portlet appUcation 
25 communication cUent for matdring session timeouts between portal server and the web 
appUcationbyre-autiienticating the user ifthew* application times out before the portal server. 

Another aspect of «ie invention provides a portlet application capable of operating on a 
portal server for hostii^ multiple assodated portlets in a web portal accessfole by a user, tiie 
portal server providing messaging means for aUowing flie assodated porflets to message eadi 
30 other, includmg: 
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porflet application means for managing die multiple associated portlets; 
eadi assodated pordet having a pottlet descriptor describing contact narne^ 
the associated portlets including coUaboration groups of portlets having corresponding 
context names defining context valuer 
5 each the group of pordets including a master portlet and at least one slave porflet; 

wherdn eadi the groiq> of portlets share contrait names in common; 
means m fhe portal server for broadcasting communicating changes in context values of a 
mastCT portlet to slave porflets of the masto: portlet; 

means in tiie portal server for changing context vahies of flie slave pordets to match 
10 context values of the master portlet as broadcast 

Anodier aspect of die invention provides a pordet appUcation capable of operating on a 
portal server for hosting multiple associated portlets in a web portal accessible by a user, die 
. pcHtalservor having portlet refresh capability, including: 

pordet application means for managing die multiple associated pordets; 
IS each assodated pord^ having a pordet descriptor; 

each porflet descriptor induding refresh priority description for die pordet; 

the assodated pordets including collaboration groiqis of pordets; 
eadi the group of portlets including a master porflet and at least one slave portlet; 
means in die pordet appUcation means for refrediing die pordets in order of didr refresh 
20 pricmties. 

Still anodier aspect of the invention provides a pordet appUcation capable of operating on 
a portal server fi*r hosting multiple assodated portlets in a web portal accessible by a user, die 
portal server having portlet refresh capaWUty, including: 

die associated portlets including coUaboration groups of porflets; 
25 porflet appUcation means for managing tiie multiple associated porflets; 

eadi assodated porflet having a porflet descripton 

each portlet descriptor including a refresh priority description for flie portlet, and a refresh 
description priority for die group of portlets of whidi die portlet is a member; 

each die group of porflets including a master portlet and at least one slave porflet; 
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means in the pordet application means for refreshing the portlets in order of their 
priorities; 

means in the portlet application means for refteshing the collaborative groups of portlets 
in order of their group refresh priorities. 

5 

The master portlets have higher priorities than slave porflets. 

Preferably the portlet application refreshes the groiq?s first in group priori^ order and 
then refreshes within each group in priority order. 

Another aspect of the invention provides apparatus for displaying to a user a web page 
10 session for a web application, the web page session displaying a plurality of associated 
collaborative portlets, sharing information with each oth^, accessible by the user including: 

a portal server for operating a web portal to provide access to the web application; 

a portlet application, for managing a collection of associated portlets, for operating on the 
portal server; 

IS access means to access a rules database; 

flie rules including rules controlling display of sets of portlets, pages, page groups to 

\xsers; 

selection means to select a set of portlets, pages, and page groups to be displayed to a 
user based on inforniation provided by the user (information properties). 
20 In another variation of the invention the selection means includes a pluggable rules 

engine, a rules database, and a portlet application aggregation engine which applies mles to select 
and display selected portlets, pages, and page groups to a user. 

Another aspect of the invention provides ^aiatus for displaymg to a user a web page 
session for a web application, the web page session displaying a pluraUty of associated 
25 collaborative porflets, sharing information wifli each other, accessible by the user including: 

a portal SCTver for operating a web portal to provide access to the web application; 

a portlet application, for managing a collection of associated porflets, for operating on the 

portal server; 

roles access means to access a roles database; 
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the roles database containing rules controlling display of sets of porttets, pages, page 

groups to users based on vset roles; 

role selection means to select a set of portlets, pages, and page groups to be displayed to 
a user based on an identified role of the user. 
5 Other aspects of tiie mvfflation provide an article includmg: 

a computer readable signal bearing medium; 

computer program code means recorded on the medium adapted to perfiirm the methods 
of the embodiments of the invention described above. 

Other aspects of the invention provide an article including: 
10 a computer readable signal bearing medium; 

computer program code means recorded on the medium adapted to implement the 
apparatus of any of the embodiments of the invention described above. 

The medium may be selected from the group consisting of magnetic, optical, biological, 
and atomic data storage media as appropriate. 
15 The medium may be a modulated carrier signal. 

The signal may be a transmission over a network. 

H^ f nftBcriptioii i}t *lte Draiwings 

Embodiments of the present invention wUl be described by way of example, referring to the 
20 accompanying drawings in whidu 

Figure 1 depicts a Dynamic Context Ctiaining Model; 
Figure 2 depicts a Web Application Integration Wifli Portal; 
Figure 3 depicts an Integration Structural Diagram; 
Figure 4 depicts an Integration Flow Diagram; 
25 Figure 5 depicts a Structure Diagram for Portal integration with Web AppUcation; 

Figure 6 depicts a Flow Chart for Integration; 

Figure 7 depicts an Example Of Dynamic Context Groups for Portlets; 
Figure 8 depicts a Portlet Application Initialization For Dynamic Context As Specified In 
the definition instance; 
30 Figure 9 depicts a Dynamic Context Portiet C3roup Run Time Flow; 
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Figure 10 depicts a Role Based Dynamic Aggregation Con^nent Structure Map; 
Figure 1 1 depicts a Rule Based Dynamic Aggregation Conqionmt Flow Map; 
Figure 12 depicts a Role Based Dynamic Aggregation Flow Chart; 
Figure 1 3 d^cts the handling of poitlels requests to web qn>licatioi>s* 
5 Figure 14 depicts a sync modd diagram; 

Figure IS d^icts a flow diart for a sequence aware portal i^grei^on oigin^ 
Figure 16 depicts the defining of a dynamic group called **MaleTeen" and assigning users 
to the group; 

Figure 17 depicts the assigning a rules database contott group selection action to a 

10 ^mamic user group; and. 

Figure 18 depicts the creation of a new action called "maleTeenAction". 

Hfffa«ftd Peggription of Preferred En ^^^ndimeBts of the Invention 
This section describes prefoxed enibodimaits of the inventioiu 

15 

A.1. Portal and Wdl> Apj^cations Integration Enablement 

Figure 2 iUustrates a preferred embodiment of the mvention illustrating its use with a web 
portal server. 

20 A.1.1 Porttet Application http client 

The porttet (tiiat makes http requests to the back end web appUcation) uses the Portiet 
AppUcation Http cUent 209 used to open an Http connection to a badcend web appUcation fliat 
runs on a backend appUcation server 210. The badcend web application requires a Portiet 
AppUcation Http cUent 209 to provide session support over multiple requests and responses, 
25 cookie handling and Single Sign on (SSO) logic. All flie portiets in the same porttet application 
use tiie same portiet application Http cUent object 209 to connect to one or more badcend web 
appUcations. There is one Portiet AppUcation http client 209 per portiet application 204. 

A.1.2 Portiet AppUcation Session 
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The Portlet Application Session object 208 is a unified data store object tiiat can be 
shared by all portlets in a given portlet appUcation. This object ejdsts per user and per portlet 
appUcatlon. Ttie Portlet Application Sesaon object 208 provides infrastructure so that multiple 
portlets in a given porflet application wiU have independent user sessions (called portlet sessions 
5 204 205^06) but share the same Portlet AppUcation Session, and communicate with the weto 
appUcation on the backend iq>pUcation server 210 with a smgle web j^Ucation session- 

A.1.3 Pordet appUcation session contort 

Pordet AppUcation Session Context provides information fliat is per user and per portlet 
10 appUcation. This means that aU portlets within tiie same portlet application (204, 203) can now 
have a way to share common information among tiiem. 

A.1.4 Session Relay Mechanism 320 

Tbt Session relay mechanism enables tiie passing of information from the original http 
15 session held by the portal server to tiie back end http session created by the portlet application's 
ht^ cUerit This mechanism uses the foUowing infrastructure: 

Cookie Table 305 & Cookie Lookup Key 

Cookie table 305. (a user session information table) is tiie main entity for mapping tiie 
20 portal server cookies to tiie backend web application session cookies. The mapping relationship 
between tiie cookie of tiie http requests tb tiie portal server and ttie cookie of tiie portlet 
appUcation http dient to one given web application is one tt> one. However, A given portlet 
appUcation http cUent can make http requests to different web applications witii eadi web 
appUcation maintaining independent sessions. Witii tiiat regard, tiie mapping between tiie portal 
25 server session cookie and tiiat of tiie backend web applications can be one to many (due to 
multiple backend web appUcation servers). 

Figure 13 depicts diis mapping, in which a number of items are iUustrated: 
RQl : cookie from tiie http request of a user agent (browser) to flie portal server 
RQA: cookie from tiie http request of flie portlet http appUcation cUent to tiie web 
30 i^lication A. 
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RQB: cookie fiom the http request of the porUet http appUcation cUent to the web 
application B 

The Portlet Application Http client 209 uses this table to look up the matching cookie to 
the backend web ^plication running on the backend web application server 210. 

Hie existence of this cookie mapping table 305 enables the automatic expiration of a 
backend web application session when the portal server session expires. 



Cookie Lookup Key 

The portlet appUcation http client 209 is created per portlet application. The cookie 
10 lookup key is stored in the portal application session object which is accessible to all the porflets 
within the same portiet application. This cookie lookup key is responsible for matdiing the http 
session of the portal server with the http session of the back end application. 

The use of the cookie looloip key allows all porttets in a given portlet application who 
share the same Http CUent key to retrieve and forward the correct set of backend web application 
15 information for the currently logged in user such that all the portlets in the same portlet 
appUcation work in symtoonization to update the back«id web application being used. The 
effect is that the end user sees a unified view of the badcend web appUcation through multiple 
portlets. 

20 PoiHet Request Parameter Map 

The Portlet Request Parameter Map 308 is in a memory object stored m the shared 
application session data store whidi is <«ated per portlet, per portal server session. It is used to 
store all request parameters fifom an incoming user request to a particular portlet. 

25 A.2. Dynamic Content Synchronization of Portlets 
A^.l Dynamic context Definition template 

Figure 5 iUustrates portal integration with a backend web appUcation. Reference to 

Figure 5 wiU be useful for the following: 

The Dynamic context Definition template 503 defines the foUowing for each Dynamic 

30 Context Group: 
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- fte context and its type (in our previous example, it is the Account ID) 

- flie master portlet who can dunge the value of flie context defined 

- the slave portlet(s) who get notified when the defined context is changed 

- tbs slave porfletCs) registered response (or action) upon notification of ttie context 

S change 

- optionaUy defines flierefiesh sequence ofthe slave portlets (master always get 

refreshed first within agiven grov^) 

One Dynamic Context Definition Template 503 can contain one ormany Dynamic Context 
10 Group(s). But each Dynamic Context Group can only have 
. one mast^ portlet 

- one defined context 

- one or more than one slave portlets 

Notes: a given porflet can participate in more than one Dynamic Context Groups 

15 with different roles in each group. 

AA2 Dynamic Context Portlets Grouping Generation Tool 

This tool 501 reads in the Dynamic Context Definition Template 503 and generates 
Dynanuc Context Master Portlet and Slave Porflets for dl Dynamic Con^ 
the definition specified by updating flie portlet dej^oyment descriptors 502 concs^ondingly. 
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Dynamic C<mt^ Group 

A dynamic context group is a subset of portlets that share the same context and are 
grouped under one dynamic context group. A given portlet can beJong to more «ian one ^manric 

context group. 

25 The Dynamic context group definition document instance 504 is used to define the 

dynamic context of a particular dynamic context group). 

nypam^ c Cfltitey t Master portlet 
Dynamic Context Master Portlet is responsible for 
30 . detecting the context state dian^ 
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. notifying all slave portlets on the context state change 

nynm^^fi r»ntext Slave nortletfs^ 
Dynamic Context Slave portlets do fhe foUowmg: 
5 . pulling for context change as notified by Ihe master portlet 

- performs the registered action directed towards the corresponding back «id 
ai^lication i^on notification of context diange 

Pynamic Context Models 
10 There are two types of Dynamic Context models tiiat can be used for associating porflets 

with each other: 

4 

TheSync model 

In the Sync, modd, depicted in Figure 14, the master portlet 101 mfonns the slaves 
15 1701-1703 about the state diange of the context of the Dynamic context master portlet. All 
slaves will perfbnn actions based on a previously defined response to sync up with the master*s 
context state diange. 
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Sync model diagram 



A^^ The Chaining model 

In the diainmg model, indicated in Figure 1, the change of state in Master A 101 results 
in the response action of Slave A 102, Slave A is also the Master portlet B, whidi leads to fee 
change of state in context B, resulting in the context diange response of Slave B 103, slave B is 
25 also the master portlet of dynamic context group C, resulting in flie action response of Slave C. 

A^.6 Porttet Transaction Manager: 

A Sequence Aware Portal Aggregation Engine Extension Referring to Figure 15, the 
portlet transaction manager 1802 is the component responsible for managing the runtime refresh 
30 sequencing of the portlets including the creation of portlet requests, responses, and sessions. 
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1 . The first porflet to be refreshed for any pordet application is defined as that portiet which 
is refreshed first among all the portlets for a given user. There is no existing mechanism to 
define fiie refi«shing sequence of portlets xtifian a ^ven page. 

Thus, we need some logic which can identify the master porflet dynamically at runtime. 

5 In the present invention we use a simple scratchboard where each portiet makes a mark every 
time it is refredied. the first time a portiet makes a mark on this scratdAoard it knows that it is 
the first or master portiet The next portiet fliat makes a mark on this Ust can already see that 
other portiet has made a mark on it and knows that it is not the master portiet, etc. Tlie next time 
the portal page is refreshed, the first portiet that makes a double mark on this list becomes the 

10 master portiet. The master portiet then, reinitializes fliis Ust by removing flie marks of all the 
other portlets and also one of its double marks for the next request This algorithm allows us to 
detect the master portiet dynamically every tune a request comes in fi»m the portlets* portal 



server. 



After the first portiet is refreshed the transaction manager takes over to refresh the other 
15 portlets in the sequence as predefined in the master and slave portiet mapping of the dynamic 
cont^t group. 

2. Sequence sorter: The sequence sorter module 1804 is used to sort the portlets in their 
refresh sequence order. It used the portiet deployment descriptor to identify the refresh order of 

20 each portiet and thrai sorts them out for the request dispatching engme. 

3. Seqaence Aware Request Dispatching Engine Extension: This engine 1805 is used to 
dispatch requests to the portlets and over-rides the portal aggregation engine. Bs job is to 
construct the appropriate portiet request and response objects, as well as the portiet session for all 

25 the portlets m the commerce portal application. It is then used by &e transaction manager to 
actually refresh the portlets. 

4. Transaction Manager Caching Unit: The transaction manager caching unit 1806 is 
used by the transaction manager 1802 to cache the responses produced by the portlets as they are 

30 refreshed by the request dispatching engine. This is necessary as when the portal aggregation 

CA9-2002-0069 23 



• 



CA 02406713 2002-10-04 



engiiie now requests for a porttet teftesh, these cached responses are sent back to it by the 
transaction manager. This avoids the problem of double reftesh per incoming portal request. 

A3. Rule Based and Role Based Aggregation 
5 Figure 11 iUustrates a rule based dynamic aggregation component structure map of a 

preferred embodiment of this invention. A description of flie components of the illustrated 
embodiment and their operation follow: 

Portal Resource Translation Module 
10 Hie portal resovirce translation module 1015 is responsible for translating the set of Portal 
resources including: portlets, pages and page groups into a form that can be parsed and processed 
by the external rules engine 1022. 

Roles Database 

15 The rules database 1001 holds busuiess manager defined rules for the portal aggregation 

engine 1006. 

User Resource Translatloii Module 

The user resource translation module 1013 is responsible for translating user resources 
20 and tije various user properties into a form that can be parsed and wMked upon b^ 



rules engine. 



Pluggable Rules En^e 

The rules engine 1022 is an external, pluggable rules engine (in this embodiment of the 
25 invention), such as the websphere™ personalization enguie, fliat is used for dynamic rule parang 
and execution. The engine's execution produces the set of portal resources that tiie user should 
see based on tiie business rules defined by the business user and the user properties of the current 



user. 



30 Portal Roles Based PersonaUzation Engine 
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The Portal roles based personalization engine 1008 is a roles based resource selection 
module that is used for extracting the list of portal resources a user is allowed to access and flie 
list of portal resources the user is not allowed to access based on tiie user»s organization 
memboiship. 

5 The roles based engine 1008 first looks at tiie user's organization by accessing tiie roles 

database 1007. Once tiie user's organization has been determined, his role is assumed to BE tiie 
same as tiie role of tiiat organization. After tiiis tiie roles based personalization engine 1008 
extracts tiie list of resources tiiat have been defined as accessible and inaccessible for tiiis 
organization by ttie business user. Once tins list has been detemrined FT is forwarded by tiiis 

10 module to tiie portal aggregation engine's aggregated resource translation subsystem for fiirtiier 
processing. 

Roles DB 

The Roles DB 1007 holds tiie organization data for tiie portal server. It holds information 

15 about organfaation membership for various us«:s and also tiie list of portal resourc^ tiiat 
members of an organization can and can not access based on tiieir roles. 

Portal Aggregation Engine Aggregated Resource Translation Subsystem 

Tbis module 1004 is responsible for abating tiie master list of portal resources tiiat tiie 
current user is aUowed to see (tins includes portiets, pages, and page groups) based on ttie output 
of tiie rules and roles based personalization engmes. This module is also an adapter for tiie actual 
portal aggregation engine. Its job is to not only create tins master Ust but also to translate it into a 
form tiiat can tiien be accessed by tiie actual portal aggregation «igine for creating flie final web 
site for the end us^. 
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Part B: Operational Description 

B. 1 Portal and Web Application Integration Enabling Description 
B.1.1 Overall Integration Structure & Flow Diagrams 

Figures 2, 3. and 4, depict respectively: web application integration witii a portal; an 
30 integration structtiral diagram; and an integration flow diagram. 
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B.1.2 Detafled Description 

Refening to Figure 2, when a badcend w* appUcation is integrated with portal server, 
the badcend web application 221 receives requests from the portal server 201 via portlets. The 
badcend web application 221 sends responses back to the portlet making the request. 

The response ftom the web appUcation 221 is rendered via portlets of the portal server 

201 to a user accessing the portlet. 

With the implementation of the Portal Application HTTP cUent 209 multiple requests and 
responses to the backend web application are percdved by the bade end web appUcation as 
cohesive sessions. The Portal Application Http cUent 209 is used to open Http communication 
c<mnections to the backend wd> appUcation 221. The backend web appUcation requires the Portal 
AppUcation Http cUent 209 to provide session support, cookie handUng and Smgle Sign On 
(SSO) c^abilities. With the Portal AppUcation HTTP cUent 209 in place, the portlete can 
effectively communicate with web application. AU the portlets in a portlet application (such as 
portlet appUcation 205) need to have access to one portlet appUcation session object 21 1 of the 
back^ appUcation 221. that means that Portal Application Http cUent 209^ be shared by 
aU the portlets within die same portal j^Ucation. 

To make sudi sharing possible we have deteraiined that a unified session object that can 
be shared by all portlets in a given portal appUcation is needed. To provide such an object the 
invention herein provides a Portlet AppUcation Session object 208. The Portlet Application 
session object 208 is an object that is created by the commerce portlet appUcation. The portlet 
application session object 208 is accessible by aU portlets in a given portlet appUcation (such as 
portlets 204, 205. 206 in portlet appUcation 1. 207). Wiflujut the portlet appUcation session 
object. 208, multiple portlets in a given portal appUcation will all have mdependent user sessions 
and wUl not be able to share session rdated information. 

The Portlet AppUcation Http client 209 is stored in die Portlet AppUcation Session 208, 
making it possible to share it among portlets in the same portlet appUcation. Without this portlet 
application session object it would not be possible for the portlets to communicate with a smgle 
web appUcation session on the backend. 
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AH the data that is stored in the Portal Application Session object 208 represents Portal 
Application Session context and exists per user per portal application. 

Since the Porttet AppUcation http client 209 holds all session information for the 
badc-end web application 221, it is used as a base for the Session Relay mechanism 320 depicted 
5 in fig. 3. 

Session relaying allows session information to be relayed that is specific to the whole 
portal server 201 (such as language information, user agent information, etc) to Ae session 
infonnation of the back-end web application 221. That means that the back-end web application 
221 is able to dehver the data representation that conforms to all &e requirements contained in 
10 the original request sent to the portal server by a user. 

For example, if the user accesses the portal using a WAP (wireless application protocol) 
enabled mobile device, with default language locale set to ♦Trench" then The original http 
request to the portal server 201 wUl have ITS language parameter set to "French" and i^er-agent 
fidd of the HTTP header set to "WAP". The Session Relay mechanism 320 relays this 
15 information to the web-appUcation 221 and the web appUcation returns a response in French that 
is suitable for display on the user's mobile device in French. If the Session Relaying were absent 
tbe web-appUcation would return the information in the defeult-language (for example EngUsh) 
suited for the defiiult device (for example an Memet Browser). In that case the user would not be 
able to see the retrieved data as it would be incompatible with the user's mobile device. 
20 Reference will be made to elements in the structural diagram Figure 3 while process steps 

of Figure 4 wUl be indicated by enumarate stqps. 

Step 401. the user interacts with portlets on a web portal, for instance by using a 
computer mouse to cUck on a link or object displayed in a porflet on the user's web browser . 
Each portlet has its own pordet session 310 (porttet session is a piece of prior art). As part of the 
25 user interaction, a remote request 306 is being made to be backend web appUcation 307. 

2. Step 403, in order to pass aU the parameters in the portlet session correctly to the backend 
web application each portlet request's parameter list is saved in the Portlet Request Parameter 
Map (#8) 308. These parameters are passed to the remote back end request. 
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3. Step 404, the commerce portlet uses a http cUent key 301 to detennine if there is akeady 
an existing Portlet AppUcation Session Object 208 and Portlet Application Http CUent 303 by 
accessing portlet application data store #4, 302. step 405, If one is not found, a new one wiU be 
created for all the portlets within the same portlet application. (Step 407, If one is found, the 

5 existing one will be used instead.) 

4. Step 406, each user credential from the original porflet session is saved in the cookie table 
305. 

10 5. Step 408, the user credentials from the cookie table 305 and the parameters previously 
saved in the portlet request parameter map 308 are used to construct a new http request to the 
badcend web application. . 



15 



6. Stq> 409, the call to remote web application is made 307. 

7. Step 410, flie remote web appUcation 307 returns a response to the call for the portlet to 
display. 

B.2 Dynamic Context Synchronizatioii of PoiHets 
20 B:Z.1 Development Time Description 

Referring to iFigure 5 which depicts a stmctural diagram of portal integration with a 
backend web application, it may be seen that a portal dweloper can make use of the Dynamic 
Context Portlet Grouping Tool 501 to create eadi new Dynamic Group Definition Instance 504 . 
This instance is a grouping of associate portlets and defines which portlets are slaves and which 
25 portlet is the master of those slaves. The required elements of the Dynamic Group Definition 
ARE specified in the Dynamic Context Group Definition Template 503. 

User uses the same tool 501 to update an existing Dynamic Context Group Definition. 

After the user has provided the latest dynamic context group definition, the Dynamic 
Context Portlet Grouping Tool 501 updates the appropriate portlet appUcation deployment 
30 desoiptors 502 to reflect the relationships defined in tiie group. 
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RefeniQg to Figure 6, a flow chart rqwesenting portal integratian Ae steps of the above 
process may be more clearly visualized: 

When a user vwinls to aeate (608) or update (609) a dynamic context group, the user can 

employ Ae gFOiq>ing tool 501 (Fig. 5). 
5 601, the dynamic context grouping tool prompts for user ii^iit based on what is specified 

in the dynamic context group definition template 503, or in the case of updating ihe dynamic 
context grouping tool reads m an existing dynamic context gioup instance. vaUdating it wifli fiie 

definition template 503. 

603. the user specifies flie required infomwtion to define or update a dynamic context 

10 group. 

605, the dynamic context group instance 504 is generated. 

606, the deployment descriptor of all related porttets are ifl?dated. 

pvnamic Co ntevt Grouping 
15 Figure 7 iUustrates dynamic context for portlets. Dynamic group 701 is conqoised of 

master portlet 704, slave portlet 705, and slave portiet 707. 

Group 703 is comprised of master portlet 705. slave portlet 706, and slave portlet 707. 
Dynamic group 702 is comprised of master portlet 704 and slave portlet 708. 
If the data that is teprwented by portlets in a Portlet AppUcation is synchronized at tiie 
20 badc-end appUcation level, then &e portlets ddiver a coordinated view of the data just by 
retrieving that data ftom the web ^Ucation. However, not all porflet interactions result in the 
changes at tiie backend w* application. Dynamic context serves as the syndm>nization 'at the 
glass\ It is most effective when a diangeii context requires a difflwent query. For example, 
selecting a different account ftom the account Ust requires displaying of invoice informafion 
25 being reftedied with the accoxmt selected. 

In prior art systems Portlets were normally independent of each another. This invention 
provides method and apparatos to m*^ the relations of portlets with each other and articulate 
their dependency on each other at portlet appUcation deployment and configuration time. The 
portlets thonselves do not need to be changed. 
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TTie dependency relationships among porflets can be defined in a Dynamic Ck)ntext 
Relationship Template 503 in wWch the master and slave relationships are defined 

TTie Dynamic Context Relationship Template 503 is preferably encoded as an XML data 

iq^yresentation that defines the following: 
5 . the subset ofportlets that constitute a dynamic context groi5> 

- the piaster portlet of a dynamic context group 

- the filavefs^ portlet of this dynamic context group 

. the slave action that the slave(s) have to perform upon context state changes 
. the conlert that all constituents of this dynamic context group share 

10 

An example of a Dynamic Context Group definition instance follows: 

<DynamicContextGroup> 

<DynaKdcContextGroupName>OrderRelatedPortletGroup 

j5 </DynamicContextGroupName> 

<DynamicContextMasterPortlet> 

• Orderltems 
</DynamicContextMasterPortiet> 

<DynamicContext>iteinName 

20 </DynamicContext> 

<DynaiaicContextSlavePortlet> 

<DynamicContextSlavePortletName>UPSTracl€ing 

</ DynamicContext SlavePortletNaine> 

<SlavePortletAction> 
25 ^t^-p I / / i n ^T^r^^QrMserM^T . com/ inStockZ 

< / s lavePort le t Act ion> 
</DynainicContextSlavePortlet> 
</DynamicContextGroup> 

30 <DynainicContextGroup> 

<DynamicContextGroupName>StookInventoryPortletGroup 

< /DynaioicContextGroupNaiae> 
<DynamicContextMasterPortlet> 
InStocklnventory 
35 </DynamicContextMasterPortlet> 
<DynamicContext>iteniSKUnuiober 
</DynaxaicContext> 
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<Dynami oCont ext s lavePor tlet > 

<DynamicContextSlavePortletNBine>Orderedltem8 

</DynamicContextSlavePortletName> 

<SlavePortletAction> 

http://inyserver.coin/lastOrdered/ 

</SlavePortletAction> 
</DynamicContextSlavePortlet> 
</DynamlcCoiitext6roup> 



The dynamic context group Definition Instances note: one dynamic context group 
definition is one instance. However, multiple dynamic context group definitions can be 
consoUdated into one file to define multiple instances above defines two portlet sets in a porflet 
application consisting of 3 portlets. 

^ In the first dynamic context group, the dynamic context shared between the portlets is 
15 itemName. the portlet named Orderedltems serves as Dynamic context Master portlet and 
portlets UPSTracldng and InStoddnventory serve as flie Dynamic context Steve poitlets. 

In the second dynamic context group, the dynamic context shared between the portlets is 
itemSkuNumber, the porflet named InStocklnv^toiy serves as Dynamic context Master porflet 
and porflet Orderedltems and serves as the Dynamic context Slave porttets. 
20 Each Dynamic context Master porflet observes a user HTTP request and looks for flie 

dynamic context If flie dynamic context is found in die request, the dynamic context porflet 
sends a dynamic context (which is flie name and value pair parameter m flie htip request) to flie 
Slave porflets. 

For example if Orderedltems portlet receives an HTTP request wifli attribute itemName 
25 set to "PeotiumlV" it sends flie dynamic context to flie portlets UPSTracking and 
InStoddnventory noticing fliem fliat context itemName witii value "PentiumlV" was now set in 
the dynamic context 

Each Dynamic context Slave portlet listens to flie master»8 notification to all slave 
portlets of flie same dynamic context group. Upon receiving flie master's notification, flie 
corresponding slave action is invoked by adding flie dynamic context to flie action URL as 
defined m tiie dynamic context group definition mstance under attribute 'SlavePortletAction'. 
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For example if inStoddnventoiy porflet receives the dynamic context from Orderltems 
portlet with dynamic context type IteniName" and value ««PentiuniIV" it wiU retrieve the data 

thA //^T.^en^:Qr y «^rv*^r■eom/^n.St.oclc/lte^^^^?>n>e»pen^;^^m;^^t URL- 

Coding for an example of a Dynamic Context CSronp Definition Template follows: 

<x8d:schenia 

xmlns3«d«l>ttp:/AMww.w3.org/2001/XMLSchema" 

xmlns:ceps 



10 

<annotatlon> 

<documentation xml:langs^en"> 

Schema for Websphere Commerce Enabled Portal Dynamic Context Group Definition 
Copyright 2002 IBM CorporaHon 
15 <documentation> 
<annotatioh> 

<!— Dynamic Context Group Instance -> 
<xsd:eiement name=T3ynamlcContBXlGroup" 
20 type=^DynanticConte>*QroupDellnlHonTemplate", 

mlnOccurs=^1"/> 



<!— Dynamic Context Group Definition Template Schema _ 
25 <x8d:complexType name="DynamlcContextGroupDefinl«onTemplate"> 

<xsd:8equence> 

<xsd:eiement name="DynamlcContextGroupName" type-'^^trlng-^ 
<x8d:element name=T3ynamlcContexlMasteiPortler type^PortletName-> 
<I- only one dynamic context per dynamic context group -> 
30 <xsd:element name=-DynamlcContext" typer^ContextParameter maxOccur8=-1-/> 

<xsd:element name=TDynamlcContextSlavePortlet" type^SlavePortlef 

mlnOocur8="1"/> 



35 



</xsd:sequence> 
</ksdxomplexType> 



<xsd: 
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<xsd:sequence> 

<xsci:elemenl name="DynamlcContextSlavePortl0r type="PortletName"/> 
<xsd:element name="SlavePortletActlon" type=^xsd:strlng"/> 
<xsd:element names'SlavePortletRefreshPrlorlty" types^xsd:declmar, 

mlnOccurs="0''/> 

<!- master's context is in the slave action url If slave param map Is absent -> 
<xsd:element name^'SlaveParamMapToContexr type="ContextParameter" 

minOccurs="07> 

</xsd:sequence> 
</xsd:complexType> 

<xsd:simpleType name="PortletName'^ 

<xsd:string> 

</xsd:simpleType> 

<(_ name of the parameter In master's request url -> 
<xsd:simpleType name=*'ContextParameteir"> 
<xsd:strlng> 
</xsd:simpleType> 

<X8d:schema> 



B.2.2 Rim Time 

This section will best understood by referring to Figure 8: Portlet Application 
Initialization For Dynamic Ck)ntext As Specified In The Definition Instance; and 
Figure 9: Dynamic Context Portlet Group Run Time Flow. 
There are two key component to handle Runtime aspects of the Dynamic Context: 

1) DynatnicContextActionListener (904) (Portlet Action Listener) -it listens for the 
dynamic context change in the Master portlet Master portlet in every Dynamic Context 
Portlet Group has DynamicContextActionListener attached to it. 

2) DynamicContextMessageListener (906) (Portlet Message Listener) - is the Message 
Listener Ustens for the notification from the Master of the group where specific Dynamic 
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Context is defined. Every Slave portlet in the Dynamic Context Portlets CSroup has a 
DynamicContejctMessageUstaaer attached to it. 

Step-by-st^ description of Ae run-time flow: 

5 At portlet initialization time (Fig 8: 801). all master portlets wiU add Ae defined dynamic 

context baaed on the portlet descriptor (802, 805) to the master portlet's action listener (806). For 
all slave portlets; flie dynamic context typ^, the action ud; the parameter m^g and &e 
refresh sequence, will be retrieved from ttie porlet descriptor (802. 809) and add to die slaves 
portlet message listener (810). 

10 1) The user mteraction with the Dynamic Context Portlet Group Master porflet results in 

die diange of the Dynamic Context (901). 

2) Master's Pordet DynamicContextActionlistena detects die user's action (902). 

3) DynamicContextActionListener sets the name/value pair corresponding to die 
Dynamic Context in the requests object of die Master Portlet (904). 

15 4) Master Portlet gets die value of die Dynamic Context and notifies all die slave portlets 

within the same dynamic porflet group about it (90S). 

5) DynamicContextMessageUstener associated widi die Slave portlet for die glv«ai 
Master receives die notificafion (die value of ttie dynamic context) (906). 

6) DynamicContextMessageUstener sets die value of die DynamicContext hi die portlet 
20 request object of the Slave porflet. (907). 

7) The Slave porflet gets die value of die dynamic context (1008). 

8) The Slave Portlet modifies action defined for die given Slave Portlet if die mappuig 
betweoi cont^t and some parametrar was ^edfied (1009). 

9) If die mapping was not specified, die name/value pair of die dynamic context is added 
25 to the Slave's Porflet action. 
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10) Slave Pordet perfonns the Action as defined in the dynamic context group instance 
definition (1011, 1012). 

B3 Rule Based Role Based Dynamic Aggregation 
5 A nnmbcr of figures wiU be referred to in this section including: Figure 10: Role Based 

Dynamic Aggregation Component Structure M^; Figure II: Rule Based Dynamic Aggregation 
Component Structure Map; and. Figure 12: Rule Based Dynamic Aggregation Flow Chart 

The role and rules based dynamic aggregation components for the portlet server are based 
around the rules and roles databases and the concept of content groups for each role and rule. 
10 Ihe content groups for Ihe rules are kept in the Rules DB component 1001 shown in 

Figure 10. Similarly fee roles content groiq)s aie defined in the Roles DB component 1007 
shown in Figure 10. Each content group consists of a set of portal server resources that a user 
who has been evaluated to fill under flie purview of that particular role or rule should have 
access to. ' 

15 Another m^or component in this scheme is the Phiggable Rules Engine 1022. TTietad^ 

this engine is to read in the translated user properties and decide dynamically at runtime the set of 
users who qualify for membership of a certain predefined user group based on fliese user 
properties. Also this engine maps the set of fliese dynamic user groups to the set of content 
groups that have been defined in the roles and rules DB. Preferably the Pluggable Rules Engme 
20 has a GUI to manage these tasks. The screen shot depicted in Figure 16 Ulustrates how we use 
tiie WebSphere Personalization Serv« Engme to manage these tasks. 

For example. Figure 16 ilhistrates how we define a dynamic group called "MaleTeen" 
and assigns aU male users of ages b^een 16-19 to this group. 

As shown in Figure 1 7. which depicts all users who are dynamically evaluated to be male 
25 teenagers based on their properties wUl now have the «maleteenaction» command executed for 
them which would instruct the dynamic rules and roles based portal aggregation engme 1022 to 
sdect content resource forthe male te«i group firom the Roles DB 1007. 
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At devdopment time it is the task of a business manager to assign a set of portal 
resources such as: pages, porttets etc. to a specific content group in the Roles and Rules DB. This 
is currently done by using SQL scripts that direcUy load &e Rules and Roles DB. 

5 B3.1 Rule Based Role Based Dynamic Aggregation Run Time Enabling Description 

At runtime the first command to execute for a portal user is the wrapper command for the 
rules based engine. This command is actually a proxy that starts the evaluation of user's 
properties by the actual pluggable rules engine. 

In the next step the rules engine reads in the user's properties fiom his stored profile, by 
10 . utilizingtheuserresourcetransktiohmoduletotramlatethemintoafoimthatcanbeund«^ 

byit. 

Figure 18 Illustrates the creation ofanew action called 'T^eTeenAi^on'' which s^^^^^^ 
all the portd resources thtrt have been defined in the content group called •«maleteengrp" in the 
rules DB. 

15 Figure 17 illustrates creation of a dynamic aggregation module command instructing the 

aggregation module to select the contents of the "maleteengrp" for all Ae users who fell under 
the purview of the previously created rule for classifying "MaleTeens" based on dynamic user 
properties. 

Figure 17 ilhistrates how a given business rule (eg. business nile in defining what 
20 constitutes a maleteen group) takes effect (e.g.maleTeenAction) in determM 

aggregateforagivenuser, withacertainuserpropertles. fells under such classification. 

After reading in the user properties the pluggable rules engine evaluates the dynamic 
group membership of this us« based on the rules defined for the various dynamic groups as 
shown in Figure 18. 

25 Once the set of dynamic groups for this user has been ascertained the mles engine selects 

the appropriate portal content for this user by executing the content select ion actions defined for 
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this dynamic group as shown in Figure 18. These actions upon execution return the set of portal 
resources ftom fee content groups defined for them in the Rules DB. 

The next execution step is the evaluation of the roles assigned to feis user by the roles 
engine. The roles engine uses the organization membership (extracted from the user profile 
5 properties) to extract the set of content resources for this user's role ftom the Roles DB. TTiese 
resources are then added to the already existmg list of rules based portal resources created in the 
previous set 

Tbis list is then forwarded to the dynamic Portal Aggregation Engine for execution. The 
dynamic portal aggr^tion engine then selects the portal resources identified by this list to set up 
10 the defiwltportd view for this cunreirt user. 



yfrnnmarv 

1. Common Backend Web AppUcation Integration implanentation 

With the Portlet Application Http Client and Portlet AppUcation Session, it is now 
15 possible to have a common backend web application integration model. Tbis can be used to 
enable multiple portlets within the same porttet application to communicate wife fee same web 
application backend. 

This implementation of fee invention makes it possible to: 

i. have native porflet integration wifeout lamiching SQiarate browsers, and wifeout 
20 requiring multiple prompts for user id and password to access fee same backend w* ^pUcation; 

u. make multiple requests and receive responses to/from fee backend appUcation wife 
session management 



25 



2. Simple Common system leading to simple tooUng 

•me instant invention, provides an easy and quick mefeod to integrate portlet applications 
wife an existing w* ^Ucation operating on a backend server; wife merely requinng fee 
specification of fee url of fee pertinent backend web appUcation in fee deployment descnptor of 
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Ifae portlet application, with this invention it is now possible to build tooling to take caie of the 
commonality tasks of the integrati(»i. 

3. Portia Within The Portlet AppUcation Share Common Session and Session Data 

The implementation of a pordet application session object makes it possible for portlets 
of the same pordet ^Ucation to share common data among diemselves fliat are nmque witiun a 
portlet appUcation. while at die same time being di&rent fiom diat of die original http session of 
the portal server. Hiis fedUlates die sharing of data unique among Ae pordets widiin die same 
pordet application. 
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4. Portal Session and Back End Session Sharing Common Session Data 

The session relay implementation makes possible die sharing of common sesdon data 
between a portal s«ver and its backend web appUcation. Ibis enables die back«id web 
appUcation to receive information fiom die portal server, enabUng buaness logic of die web 
15 appUcation to exploit diisinfomiation passed from die portal server. 

For example: if die current pordet state is to display die maximized view of die pordet, 
die badcend web appUcation can receive dus piece of information and take advantage of tins by 
sending back detailed business infimnation, m contrast to die normal view of a pordet. in which 
case die backend web plication would just send a summary version of die information. 

20 

5 Cohesive Back End Web AppUcation Session Distinct From The Portal Server widi die portlet 
appUcation session, portlet application session object, portlet http client, and die session relay 
xnechanism A back end web appUcation can now preserve its own session distinct from diat of 
fte portal server, bnt still share die same cookie widi diat of die portal server, "me backend web 
25 appUcation can now operate independendy and correcdy, perceiving portlet requests from 
various portlets in a portal as one virtual cUent. enabUng a cohesive session widi die backend 
web i^pUcation. 



CA9-2002-0069 



38 



Ca 02406713 2002-10-04 



10 



15 



20 



6. Single Sign On Across Portal Server and Back End Web AppUcation 

■nie session relay embodiment provides single agn-on capabUity sudi that flie user, once 
logged on to a portal server, is not required to resubmit user credentials to log on to the pertinent 
back end web application. This is enabled by means of a cookie table with one to one mapping 
between the http session to the portal and the http session fiom the portlet http cUent to the 
backend web application. 

7. Back End Web AppUcation Behavior Synchronized Wifli That of the Portal Server 

session relay embodiment enables enabling seamless integration by synchronizing 
flie bduivior of a l««ikend w* application by relaying the session 
session to the session of Ihe baick end w* appUcation. 

The following are some examples: 

■me language and locale setting in a portal server can now be passed to its backend web 
appUcation so that the backend application can now compose a response message based on Ae 
locale + language setting of flie portal servw. 

Another example is that session expiry information ftom the portal server can now be 
passed to the backend web ^plication session so that the backend web appUcation session can 
now be timed out at the same time that the portal session times out The backend wd, application 
can now be responsive to the portal state and events as relayed fiom the portal server. 



8. Synchronized Content Within The Same Portal Page 

Dynamic Context Portlet C3roiq)mg allows collaboration among portlets witirin the same 
25 dynamic context group to achieve business process and information integration and 
syndironization. 
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Each portlet is aUowed to participate in multiple Dynamic Context Groups. This provides 
a very open and simple programming model for portal administrator to group portlets into 
dynamic context portlet groups. 

The simple structure of Dynamic Context definition enables simple tooling to be buUt for 
automatic generation of Dynamic Context Master and Slave portlets for ead» groining. 

Dynamic Context Definition implementation. Dynamic Context Group, master portlet 
and slave portlet implementation C«cl«ding the slave tasks, slave context map) assist in 
providing advantages of the invention. 



10 9. AbiUty To Define Refijesh Sequence of Portlets 

The transaction manager provides the capabUity of defining a reftesh sequence of portlets 
for ihe first time. The ability to define refresh sequence of portlets enables proper implementation 
of sequential business logic U8h« file portd / portlet ardutecture. The transacti^^ 

resource sorter, ttie cadiing of Ksponses assist inproviding adva^ 
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10. Rule Based and Role Based Aggregation 

Fine level portal persomdization can only be achieved at present by dynamic aggregation. 
This is distincfly different from Ae prior art impl«nentation of tegular web appUcations in which 
tiiere is no fo«nal concept of portlets. pages or page groups appUed in accordance witii tiie 
instant inv«rtion. Fine level personalization will become moro and more important as tiie portal 
market takes off and user requirements for fine level campaign targeting etc. come in. 



The embodiments of tiie invention provide a mimber of advantages whidi are listed below: 
1 The level of personalization tiiat can be achieved by our approach is nnidi finer grained 
25 tiian Portlet administration faciUties provided by portal server today. The portlet administration 
feciUties avaUable today is by nature manual configuration. Once configured, it is static and does 
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not diange at rua tune. Hie invendon here provides a dynamic ci?)abaities to render portal 
resource based on rule. 

2. Since the portal aggregation module is a dynamic entity, tying of rules and roles engines 
5 directly to it lets ns achieve real-time dynamic aggregation capabilities without any human 

intervention. 

3. Personalization of coarse grained portal resources such as pages and page groups lets us 
perform dynamic layout. 

10 . 

4. Mudi «ore effective campaigns, contracts etc. can he set up. This is of significant 
importance to both e-Commercc retail and B2B organizations. 

• - • 

5. the invention allows a much higher degree of personalization than regular content 
15 personalization: For example, we can actually disable entire sections of a wetopage based on 

rules. This cant be done by regular personalization. Furflier, dynamic aggr^on doesn't ^ly 
to the domain of regular personalization which is content, not resource related. 
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The embodiments of the invention in which an exchisive property or privUege is claimed are 
defined as follows: 

1. For a portal serv« system for managing a ooUection of associated portletsiespMisiv 

5 requests to access a wd> application, apparatus comprising: 

poTtlet application sesaon means for saving parameters ftom user requests of associated 

porUets; and 

a portlet appUcation communication cUent linked to said portlet appUcation session means for 
communicating between said assodatedportlets and said web application to convqr^ 

10 recraved ftom said associated portlets to said web appUcation. 

2. The apparatus of daim 1 wherein said pordet appUcation oommumcation dient stores user 
session information. 

15 3. Ttw apparatus of claim iwherm said portlet ^Ucation session means conq«sM 
application session object 

4. The apparatus of claim 1 wherein said assodated portlets have portlet request parameter 
maps for storing data and instructions fiom user requests to said portlets. 

5. The appanitus of daim iwhecdn a pordet appUcation is adapted to operate on said 
server syslan for managing said coUection of assodated porttets. 

6. Tlie apparatus of claim iwherdnsdd pordet wUcation communication client hM 
25 a user session infonnadon store (mapping table) for storing user session information. 

7. m apparatus of claim 1 wherdn said portlet application communication dient indudes a 
user session information store (mapping table) for storing user session information. 
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8. The ^pacatus of claim 2 wherein said user session infonnation includes user session 
infonnation for mapping said user session information to a corresponding session of said web 
supplication. 

5 9. Tte appanitus of daim 8 wherein said user session information is selected ftom the set 

comprisinr. user id, user credentials, language preferences, sesdon timeout infomiation. session 
id. formappingsaidusersessioninfonnationtoacorrespondingsessionofsaidwAapplic^^ 

10. Tlieapparatusofdaimlwhereinsaidsessiontimeoutinfomiationincl^^ 
10 information of said portal server and said web appUcation. 

11. TTieapparatusofclaim9whereinsddsessiontimeoutinfonnationincludes^^ 
information of said portal server and said wd> appHcation. 

15 12. The apparatus of claim I wherein said portlet application communication client h^ 

bu^ for storing requests from said associated portlets to enable said communication cUent to 
provide data and instructions for said web a^lication. 

13. The apparatus of claim 12 wherdn said communication client has a request buffer for storing 
20 requests ftom said porttet request parameter mi«.s of said assodated portlets to 

communication dienttoprovidedataandinstruotionsforsaidweb application. 

14. A portlet appUcation. for managing a coUecdon of assodated portlets m a portal, for 
operating on a server providing access to a web appUcati<mby auser, 

25 said assodated porflets having portlet request parameter maps storing data and instructions 
ftom user requests to said portlets; 

a portlet appUcation session object for said user for said assodated porflets; 

a portlet ^Ucation session data store controlled by said portlet application session object; 
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a portlet appUcation communicatioa cUent linked to said portlet appUcation data store for 
communicating between said associated portlets and said web appUcation to convey user requests 
received from said associated portlets to said web appUcation; and 

said communication dient having a request buffer for storing requests from portlet request 
5 parameter maps of said associated portlets to enable said communication cUent to provide data 
and instructions for said web application. 

15. A portlet appUcation communication cUent linked to said portlet application data Store of 
claim 14 for oomraunicating between said associated portlets and said web appUcation to convey 

10 user requests received from said assodated portlets to said web qipUcation; 

said portlet appUcation communication client having a user session information store 
(mapping table) for storing user session information including selected information from the set 
of die following user session information: 5ser id, user credentials, language preferehces. session 
timeout information, session id. etc. for mapping said user session information to a correspon<fing 

15 session of said web application; said session timeout information including session timeout 
information of said portal servo: and said wd) ^pUcation. 

16. The apparatus of claim 15 further including synchronization means for said portlet 
appUcation communication cUent for matching session timeouts between said portal server and 

20 said web appUcation by reauthenticating said user if said web plication times out before said 

portal savor. 

17. The apparatus of claim 16 fiirttier including syndironization means for said portlet 
appUcation communication cUent for matching session timeouts between said portal server and 

25 said web appUcation by reauthenticating said user from stored information in said user session 

information store if said web appUcation times out before said portal server. 

18. For a portal server adapted to operate a web portal to provide access to a web appUcation; 
having a portlet appUcation operating on said portal server, for managing a coUection of 

30 associated portlets; wherein said portlet application indudes: means to initiate portlets on 
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requests of a user to access said vfA appUcation; means to manage a pordet appUcation session 
object for said portiets; and, a porflrt appUcation session object data store controlled by said 
portlet application session object for saving parameters ftom user requests for associating said 
portiets with said with said portlet appUcation session object, the apparatus comprising: 
5 a portlet appUcation communication cUent (httpClient) linked to said portlet application data 
store for communicating between said associated portiets and said web appUcation to convey user 
requests reodved fiom said associated porflets to said web ^plication; and 

said portlet application oonmiunication cUent having a user session information store 
(mapping table) for storing user session mfoimation including selected information fiom the set 
10 of the following user session information: user id, user credentials, language preferences, session 
timeout information, session id. etc. for mapping said user session mformation to 

session of said web application. 

♦ 

19. The apparatus of claim 18 wherein said session timeout information mdudes session timeout 
information of said portal server and said web application. 

20. A portlet j^Ucation. for managmg a coUection of associated portiets in a portal, for 
operating on a server providuig access to a web application by a user; 

said associated portiets havmg portlet request parameter maps storing data and instructions 
20 fiom usor requests to said portlete; 

a portlet application session object for said user for said associated portlet^ 

a portlet appUcation session data store controUed by said portlet appUcation session object; 

a portlet application communication cUent (httpOient) Ihdced to said portlet appUcation data 
Store for communicattog between said associated portiets and said web appUcation to convey user 
25 requests received fiom said associated portiets to said wA appUcation; 

said communication cUent having a request bu^ for storing requests ftom portlet request 
parameter maps of said associated portiets to enable said communication client to provide data 
and instructions for said web application. 
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21. A porflet appUcation communication client (httpCaient) linked to said portlet application 
data stow of claim 20 for communicating between said associated portlets and said weib 
application to convey user requests leoeived ftom said assodated portlets to said .^pUcation; 

said porflet appUcation communication cUent having a user session information store 
(nu^ping table) for storing user sesaon information including selected infonnation fiom the set 
of the following user session information: user id, user credentials, hmguage preferences, session 
timeout information, session id, etc. for mapping said user session information to a corresponding 
session of said web application; said session timeout information including session timeout 
information of said portal server and said we appUcation. 

22. The apparatus of claim 20 fartiier including synchronization means for said porflet 
appUcation communication cUent for matching session timeouts between portal server and said 
wd, appUcation by reauflienticattf^ ^d user if said wd> appUcation times out before said portal 
server. 
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23. ForaportalserversystemformanagingacoUectionqfassooiated.portletsre^^^^ 
requests to access a web appUcation, a mediod comprising: 

usmg portlet appUcation ses^n means for saving parameters from user requests of 
associated porflets; and 

20 Using a porflet appUcation communication dient Unked to said portlet appUcation session 
„«ans for communicating between said assodated portlets and said wd, appUcation to oonvey 
us» requests recdved from said assodated portlets to said web appUcation. 

24. The mefliod of claim 23 wherdn said portlet implication communication dient stores user 

25 session information. 

25. The mefliod of claim 23 wherdn said porflet appUcation session means comprises a porflet 
Implication session object 
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26. The method of claim 23 wherein said associated portlets have poitlet request parameter 
maps for stoiing data and instructions from user requests to said porttets. 

27. llie method of claim 23 wherdn a portlet plication is adapted to operate on said portal 
5 server system for managing said collection of associated porflets. 

28. The method of claim 23 wherein said portlet application communication dient has access to 
a user session information store (mapping table) for stoiing user session information. 

10 29. Th^ method of claim 23 wherein said portlet appUcation communication client includes a 
user session information store (mapping table) for storing user session information. 

30. The method of claim 24 wherein said user session information inchuies user session 
infomiation for mapping said user session infomiation to a corresponding session of said web 
IS application. 

31 Tbe mefliod of claim 30 wherein said user session information is selected from the set 
comprising: user id. user credentials, language preferences, session timeout infomiation, session 
id. for mapping said user session information to a corresponding session of said web application. 

20 . * 

32. The method of claim 23 wherein said session timeout information includes session tmieout 
information of said portal server and said web appUcation. 

33. The method of claim 31 wherein said session timeout uiformation includes session timeout 
25 information of said portal server and said web appUcation. 

34 THe method of claim 23 wherein said portlet appUcation communication cUent has a request 
buffer for storing requests from said associated portlets to enable said communication cUent to 
provide data and instructions for said web appUcation. 
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35. nie method of claim 34 wheran said communication cUent has a request buffer for storing 
lequests ftom said porflet lequest parameter m^ of said associated portlets to enable said 
communication client to provide data and instructions for said web appUcation. 

36. A method of using portlet application, for managing a coUection of associated porflets in a 
portal, for operating on a server providing access to a wd> appUcation by a user. 

nsing portlet request parameter m^s storing data and instructions from user requests to said 
portiets comprise; 

using a portlet appUcation session object for said user for said associated portiets; 

using a portiet appUcation session data store controlled by said portiet appUcation session 

object; 

using a portiet appUcation communication cUent Unked to said portiet appUcation data store 
for communicating between 'said associated portlets and said w* application to convey user 
requests received ftom said associated portiets to said web appUcation; and 

said communication cUent having a request buffer for storing requests ftom portiet request 
parameter maps of said associated portiets to enable said communication cUent to provide data 
and instructiOTS fi>r said web appUcation. 

37 The method of daim 1 5 ush»g portiet appUcation communication client linked to said portlet 
appUcation data store of claim 14 for communicating between said associated portiets and said 
^ application to convey user requests received ftom said associated portiets to said w* 
application; 

said portlet application communication client having a user session information store 
(mapping table) for storing user sesdon information includmg selected infomiation ftom flie set 
of ihe following user session infomiatiom user id. user credentials, language preferences, session 
timeout information, session id. eto. for mappmg said user sessionhiformationtoa«^^ 

session of said web appUcation; said session timeout infomiation including session timeout 
information of said portal server and said web appUcation. 
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38. TbB medwd of clahn 37 fiirther including using syadiioniz^ 

appUcation communicatiott dient fiar matdiing session timeouts between said portal server and 
said web appUcation by reauthenticating said user if said w«* application times out before said 
portal server. 

39. Hie mdhod of daim 38 further including using syndmmizalion means for said porflet 
application communication cUent for matdung session timeouts between said portal server and 
said web appUcation by leauAenticating said user ftom stored information in said user session 
information store if said web appUcation times out before said portal server. 



10 



40. For a portal server adapted to operate a web portal to provide access to a wd>appttcatiom 
having a portlet appUcation operating on said portal server, for managing a collection of 
associated portlets; wherein said porflet appUcation includes: means to initiate portlets on 
lequestsofausertoaccesssaidwebappUcation; means to manage a portlet application session 

15 object for said portlets; and. a portlet appUcation session object data store controUed by said 
portlet appUcation session object for saving parameters ftom user requests for assodating said 

portlets with said with said portlet appUcation session object, the method comprising: 

using a portlet application communication cUent (httpaient) linked to said portlet appUcation 
data store for communicating between said assodated portlets and said web appUcation to convey 
20 user requests recdved ftom add assodated portlets to sdd wd> appUcation; and 

said portlet ^Ucation communication dient havtag a user session information store 
(mapping table) for storing user session infonnation tadudmg selected infimnation ftom tiie set 
of tiie blowing user session taformation: user id. user credentials, language preferences, session 
timeout information, session id, etc. for mapping sdd user session information to a conesponding 
25 session of said web application. 

41. nie method of claim 40 wherdn sdd session timeout mfonnation includes session timeout 
information of sdd portd sexv&c and said wd) ^pUcation. 
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42. A mefliod of using a porflet plication, for managing a collection of associated porflets in a 
portal, for operating on a server providing access to a web ^pUcation by a user. 

using portiet request panmieter maps storing data and instiuctions fe)m user req^ 

portiets; 

5 usinga portletappUcation session object for said user for said associated portlets; 

using a porflet appUcation session data store controlled by said porflet appUcation session 
object; 

using a poiflet application communication cUent (httpCUent) linked to said porflet application 
data store for communicating between said associated porflets and said web application to convey 
10 user requests received ftom said associated porflets to said web appUcation; 

said communication client having a request buffer for storing requests fiom porflet request 
parameter maps of said associated porflets to enable said communication dient to provide data 
and instructions for said web plication. 

15 43 The mefliod of claim 42 using a porflet application communication cUent (httpCUent) Unked 
to said porflet ^Ucation data store of claim 20 for communicating between said associated 
porflets and said wd> application to convey user requests received ftom said assodated porflets to 
said web appUcation; 

said porflet ^Ucation communication cUent having a us« session information store 
20 (mapping table) for storing user session infomiation including selected information from flie set 
of flie foUowing user session infomiation: user id. user credentials, language preferences, session 
timeout infomiation. session id. etc. for m^^pmg said user session infomiation to a correspondmg 
session of said web appUcation; said session timeout information including session timeout 
information of said portal server and said we appUcation. 

44 The mefliod of daim 42 forflieriiM^luding using syndironization means for 
application communication client for matdiing session timeouts between portal server and said 
web appUcation by reauflienticating said user if said web appUcation times out before said portal 



25 
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45. An article comprising: 

a computer readable signal bearing medium; and 

computer program code means recorded on said medium adiq»ted to perform the method of 
any claims 23-44. 

5 

46. An article comprising: 

a computer readable dgnal bearing medium; and 

computer program code means recorded on said medium adapted to implement the ^aratus 
of any claims 1-22. 

10 

47. Tliearticleofclaims45or46whereinsaidmediumisselectedfiomthegrottpconsistingof 
inagnetic, optical, biological, and atomic data storage media. 

48. Hie article of claims 45 or 46 wherdn said medium is modulated carrier signaL 

15 

49. Tlie article of claims 45 or 46 wherein said signal is a transmission over a network. 
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FIG. 6 

Flow Chart for Integration 
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FIG. 9a 

Dynamic Context Portlet Group Run Time Flow 
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FIG. 9b 

Dynamic Context Portlets Group Run Time Flow 
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Rule Based Dynamic Aggregation Flow Ciiart 
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FIG. 12b 

Rule Based Dynamic Aggregation Flow Chart 
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FIG 12c 

Rule Based Dynamic Aggregation Flow Chart 
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